EXP_MULT_02
===========

Objective: Test automatic detection of path failures by REAP

Experiment: Initiate an application with all the multihoming functionalities enabled. Create a simulated 
path failure (in the path used by the traffic of the application). Check that REAP is able to detect the 
path failure (reaches the exploration path state).

Result: Succeed

Setup: Two Onelab nodes involved, one with two interfaces with addresses 163.117.140.132 and 163.117.140.165 (onelab3) 
and the other with two interfaces with addresses 163.117.140.167 and 163.117.140.62 (onelab5). This experiment 
is the same as in EXP_MULT_01, but now all the multihoming component functionality is available.

Files:

**  EXP_MULT_02/reapd_onelab3.txt and EXP_MULT_02/reapd_onelab5.txt

These files are the log files of the reapd daemon. The state of REAP is shown. REAP is innitialized to monitor 
the path in use (using pcap). It starts in OPERATIONAL state and checks that traffic is sent and received in 
the path. If one side is receiving traffic but not sending traffic for some time, the keepalive timer triggers 
and a keepalive message is sent. If traffic is not received for some time while sending, the REAP state goes 
to EXPLORING or EXPLORING OK, and probe messages are sent to check for path availability. If a new available 
path is found, dumyshimd daemon is informed of the new path, and REAP starts monitoring the new path. REAP 
state goes back to OPERATIONAL. Note that in the log files, simulated failures are issued in any of the sides, 
but each failure affects both sides of the communication so REAP detects the failures in both sides. As can 
be seen in the logs, after each failure, REAP successfully finds a new path for the communication and goes 
back to OPERATIONAL state. 